👋 Schön, dass Du hier bist! Bitte beachte, dass dieser Artikel bereits einige Jahre auf seinem Buckel hat. Seitdem haben sich nicht nur die Welt, sondern auch meine Wissenslücken, Erfahrungen und Ansichten geändert. Dennoch stehe ich hinter den Aussagen, die ich damals getätigt habe. Selbst dann, wenn ich sie mittlerweile anders tätigen würde. Bitte behalte dies beim Lesen im Hinterkopf. Danke. Und viel Vergnügen!
Wir haben jeden Tag mit Abhängigkeiten zu tun. Aber worum geht es dabei? Und worum geht es dabei wirklich?
Das Wesentliche #
Zuerst - was sind Abhängigkeiten? Das ist relativ schnell geklärt. Abhängigkeiten sind die Beziehungen zwischen meinen Tasks. Wobei “meinen” hier relativ ist. Vor allem bei größeren Projekten muss ich davon ausgehen, dass mehrere Leute an den einzelnen Aufgaben arbeiten. Und hier kommen wir schon zum ersten entscheidenden Punkt: Abhängigkeiten sind Beziehungen zwischen Menschen.
Man sollte die Dependencies bei jedem Projekt erheben. Auch, wenn es mühsam ist. Aber nur mit dieser Information kann ich meinen Critical Path berechnen. Und der ist in meinen Augen unabdingbar, wenn ich mein Projekt in den Griff bekommen möchte.
Das ändert alles nichts daran, dass ich die möglichen Abhängigkeiten zwischen zwei Aufgaben (in der Literatur oft - oder eigentlich immer - Predecessor and Successor genannt) in vier Gruppen unterteilen kann.
Finish to Start, auch FS genannt #
Der Predecessor muss beendet sein, bevor ich mit dem Successor beginnen kann. Bevor ich das Haus bauen kann, muss ich mir ein Grundstück kaufen, auf dem es stehen soll. Dieser Abhängigkeit begegnen wir am häufigsten. Wahrscheinlich, weil sie sehr einfach und geradlinig ist.
Start to Start (SS) #
Das Team muss mit Aufgabe eins begonnen haben, bevor es mit Aufgabe zwei beginnen kann. Bei dieser Abhängigkeit tun sich angehende Projektarbeiter erfahrungsgemäß manchmal etwas schwer, sie so richtig zu verstehen, aber es ist eigentlich recht einfach. Ich kann mit dem Asphaltieren einer Straße in dem Moment beginnen, in dem ich begonnen habe, das Fundament vorzubereiten. Aber eben nicht vorher. Die beiden Aufgaben laufen also nur beinahe parallel ab, Aufgabe eins muss definitiv als erste beginnen.
Finish to Finish (FF) #
Task B kann nicht vor Task A beendet werden. Um bei unserem vorherigen Beispiel zu bleiben, kann das Asphaltieren der Straße nicht vor dem Vorbereiten des Fundaments fertig werden. No na ned, wie wir in Österreich so schön sagen. Ist ja logisch.
Start to Finish (SF) #
Die hirnverwindendste und zugleich auch mit Abstand seltenste Abhängigkeit zwischen zwei Tasks. Aber sie kommt dennoch ab und zu vor. Im Grunde ist eine SF-Abhängigkeit die umgedrehte Logik einer FS-Abhängigkeit. Task B kann nicht beendet werden, bevor Task A begonnen hat.
Ich glaube, der Hauptgrund, warum sich viele so schwer mit SF tun, ist, weil die meisten Beispiele dazu komplett falsch sind. Bloß, weil ich eine Finish to Start-Abhängigkeit in der umgekehrten (und somit falschen) Reihenfolge formuliere, wird daraus nicht automatisch eine Start to Finish-Abhängigkeit. Ein anschauliches (und außerdem korrektes Beispiel) finden in wir in jedem erfolgreich abgeschlossenem Softwareprojekt: die Übergabe. Das Produktivteam muss ein System bereits warten, bevor das Projektteam seine Aufgabe beenden kann.
Noch ein Beispiel gefällig? Der Nachtwächter kann erst nach Hause gehen, wenn der Manager der Frühschicht im Gebäude ist.
Von Eseln und Brücken #
Eine gute Eselsbrücke und Verständinshilfe ist für mich
Action, cannot Rule.
Bei unserer häufigsten Abhängigkeit - Finish to Start - habe ich also für Task 1 die Action "beenden" und für Task 2 die Rule "beginnen". Task 1 muss beendet sein, sonst kann Task 2 nicht starten.
Die vier Eselsbrücken sind also:
- FS: finish cannot start
- SS: start cannot start
- FF: finish cannot finish
- SF: start cannot finish
"Aber... #
..ich habe mal wo gelesen, dass es acht potentielle Abhängigkeitsformen im Projektmanagement gibt. Was stimmt denn nun?" - Beides. Mehr oder weniger. Um die Verwirrung aufzulösen: ich kann hinter jede meiner vier Dependency-Arten ein (min) oder ein (max) stellen. Also SF(min). Oder FS(max). Damit kann ich eine Mindest- oder Maximalzeit angeben, die zwischen meinen Aktivitäten liegen muss. Normalerweise ist (min) der Standardwert.
Das Ganze ist also quasi eine Erweiterung meiner Möglichkeiten. In meinen Augen ist diese Option aber mit Vorsicht zu genießen, da sie mir viel von der Intuitivität meiner Abhängigkeitendarstellung nimmt. Aber als zusätzliche Information kann sie - dort, wo es notwendig ist - sehr wertvoll sein.
Pimp my table #
Wenn ich meine Aktivitäten in eine Tabelle verpacke (was ich als PM eigentlich immer machen sollte), kann ich das Thema Abhängigkeiten ganz einfach mit einer zusätzlichen Spalte abbilden. Und eigentlich muss ich nicht mal das machen, weil alle gängigen Projektmanagementprogramme mir diese Arbeit abnehmen.
So eine Tabelle sieht dann in etwa so aus:
| # | Task | Predecessors |
|---|
| 1.1 | Architekt suchen | |
| 1.2 | Plan erstellen | 1.1 |
| 2.1 | Grundstück planieren | 1.2 |
| 2.2 | Keller ausheben | 2.1 |
| 2.3 | Fundament legen | 2.2, 2.3 |
| ... | ... | ... |
Abseits der Zwänge #
Bisher haben wir hier nur über Mandatory Dependencies geredet. Also Abhängigkeiten, die auf jeden Fall bestehen. Ich habe aber auch die Möglichkeit, einzelne Abhängigkeiten zu Discretionary Dependencies zu erklären. Das sind solche, wo die Abhängigkeit nicht in Stein gemeißelt ist. Warum sollte ich so etwas wollen? Immer dann, wenn es um Nice to Haves geht. Wenn zum Beispiel das Management einen bestimmten Termin wünscht, aber auch mit einem späteren Fertigstellungsdatum leben kann.
Auch hier unterstützen die meisten Projektmanagementprogrammen Discretionary Dependencies und bieten mir die Möglichkeit, sowohl meinen Idealtermin, als auch die harte Deadline einer Aufgabe im Auge zu behalten.
Der Vollständigkeit halber #
Und wenn wir hier schon am Vervollständigen sind: es gibt noch eine Unterscheidung meiner Abhängigkeiten. Eine, die wir Projektmanager am liebsten nicht vornehmen müssen. Interne versus externe Dependencies. Kurz zusammengefasst, sind die internen die guten, weil ich hier die Dinge zumindest ein wenig steuern kann. Externe Abhängigkeiten führen hingegen oft zu einem Brechen des Zeitplanes. Trotzdem sind sie bei den meisten großen Projekten an der Tagesordnung.
Hier hilft eigentlich nur eines: Organisation, Organisation und noch mehr Organisation. Externe Abhängigkeiten gehören zeitlich sehr konservativ geschätzt, mit viel Luft. Und dann muss ich einen genauen Überblick behalten, bei welchem externen Vendor ich welche Aufgabe nachhaken muss.
Das wirklich Wesentliche #
Zum Schluß das, was in meinen Augen bei all der Theorie gerne vergessen wird: Abhängigkeiten gehören geplant und gemanagt, aber vor allem kommuniziert und gelebt. Es reicht nicht, alles zu erheben, schön in mein MS Project zu klopfen und abzulegen. Das ist zwar die Grundlage. Aber wenn ich es hierbei bleiben lasse, wird es unabdingbar irgendwann im Laufe meines Projektes knallen.
Was nützt es mir als Projektmanager, zu wissen, dass zwei Personen an Tasks arbeiten, zwischen denen Abhängigkeiten bestehen? Genau, nichts. Die handelnden Personen müssen Bescheid wissen. Und dann muss ich regelmäßige Kommunikation zwischen ihnen fazilitieren.
Und hier hilft mir auch die schönste RACI-Matrix nichts. Sondern es ist wie so oft: es muss einen Kümmerer geben. Und das ist die Projektmanagerin, der Projektmanager. Nur so wird mein Projekt auch ein Erfolg werden können.
#methodik #projektmanagement
Vielen Dank für Deine Zeit! Du kannst den Artikel gerne teilen. Und ich freue mich immer, von Euch zu lesen. Bilder von Randy Fath und Fancycrave auf Unsplash.
← Vorheriger Artikel: Wasauchimmer - was wir aus Zufällen lernen können
→ Nächster Artikel: Impediment Backlogs im klassischen Projektmanagement
Veröffentlicht am